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BOX PATENT APPLICATION 

Assistant Commissioner for Patents 
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In the Title; 

Please replace the current title with the new title "VERIFICATION OF TRUSTED- 
PATH COMMANDS". 

In the Claims : 

Please cancel claims 1-20. 
Please add new claims 21-28: 

1 21. (New) A machine-executed method for verifying the existence of a trusted 

2 path to a user in a computing system, the computer system including a trusted computing 

3 environment, the method comprising the steps of: 
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4 (a) upon login by a user, assigning a process identifier to the user in the 

5 trusted computing environment; 

6 (b) storing the assigned process identifier in trusted memory; 

7 (c) estabhshing a trusted path between the user and the trusted computing 

8 environment; 

9 (d) through the trusted path, displayir^g the process identifier to the user; 

10 and 

11 (e) upon the user's subsequent entry into the trusted environment^ 

12 displaying the process identifier to the user through the trusted path. 

1 22. (New) The method of claim 21, wherein the process identifier is a randomly 

2 or pseudo-randomly generated group of alphanumeric characters. 

1 23. (New) The method of claim 21, wherein the process identifier is 

2 pronounceable. 

1 24. (New) An automatic data processing machine programmed to execute the 

2 method of any one of claims 21 to 23. 

1 25. (New) An automatic data processing machine comprising means for 

2 performing the method steps of any one of claims 21 to 23. 

1 26. (New) A program storage device readable by a machine and tangibly 

2 embodying a representation of a program of instructions , adaptable to be executed by said 

3 machine to perform the method of any one of claims 21 to 23. 

1 27. (New) Apparatus for executing a trusted command that is issued by a user and 

2 that is parsed by untrusted parsing means to generate a parsed command, comprising: 

3 (a) trusted means for receiving the parsed command via a trusted path; 

4 (b) means for displaying a representation of the parsed cormnand to the 

5 user for verification; and 

6 (c) trusted means for executing the verified parsed command. 
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28. (New) A program storage device readable by a machine and encoding 
machine-executable instructions that include instructions for performing the methods of any 
one of claims 21 through 23. 



REMARKS 



This Preliminary Amendment presents new claims 21-28 which are directed to 
verification of trusted-path commands. Claims 21-28 essentially correspond to non-elected 
claims 10-16 and 21 from the parent case. Unlike the non-elected claims 13-15 and 21 in the 
parent case, new claims 24-28 depend only from the claims in this case. 

It is respectfiilly submitted that the present application is in condition for allowance 
and such actions are respectfiilly requested. If there are any questions or comments regarding 
this Preliminary Amendment, the Examiner is encouraged to contact George W. Jordan III or 
David R. Clonts at (713) 220-5800. 



AKIN, GUMP, STRAUSS, HAUER & FELD, L.L.P. 
711 Louisiana, Suite 1900 
Houston, TX 77002 
(713) 220-5800 
(713)236-0822 Fax 



Respectfully submitted. 
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1, BACKGROUND OF THE INVENTTQN 



1,1 Introduction 

This invention relates to a method f0r improving security in a 
computer system. More specifically, this indention concerns a method 
for implementing trusted commands throughj both trusted and untrusted 
code. 



1.2 Background 



The proliferation of computers has reisulted in the need for 
reliable computer security systems. The neeii to protect certain 
information is great in areas dealing with national security, for example. 
Security measures are required in other field^, including areas which 
utilize financial, medical, and personal inforriiation. Many computerized 
information systems therefore include intemail security measures which 
provide the users with different levels of access to the computerized 
information, and which attempt to provide at least a degree of 
protection of the information from undesirable access. 



1 1.3 Security Criteria: Reference Validatioh Systems 

I 

2 

3 In response to the need for secure cpmputer systems, the 

4 Department of Defense has issued a publica^on titled Department of 

5 Defense Trusted Computer System Evaluatidn Criteria (reference No, 

6 DOD 5200.28-STD). This publication is son^etimes referred to as the 

7 "Orange Book," and is available from the Department of Defense. The 

8 Orange Book describes system security objectives and evaluation criteria 

9 for secure computer systems. 

A "secure" computer system generally includes some type of 

J^IJl2 "reference validation" system. These reference validation systems (known 

^5 '3 as reference monitors) are responsible for eiifbrcing the security rules 

1 14 (security policy) for a given computer system; 

Sjl5 

ajl6 Reference monitors mediate all access to "objects'* by "subjects". 

Ca7 Objects are passive entities that contain or receive information. Access 

18 to an object implies access to the information that it contains. Subjects 

19 are active entities, generally in the form of al person, process or device 

20 that cause information to flow among objects or change the system state. 

21 A subject may ordinarily reference its own, sibject-intemal information 

22 without the involvement of the reference monitor. Reference monitors 

23 controlling such access to objects by subjects are known in the art, and 

24 may utilize a security kernel approach. 

2 



Proper implementation of a reference! monitor calls for adherence 
to three principles: 



(1) completeness, in thatj all access by 
subjects to objects or other subjects must 
involve the monitor; 



(2) isolation, in that the Imonitor must 
be protected from tampering; ahd 

(3) verifiability, in that correspondence 
must be shown between the security policy 
and the actual implementation 6f the monitor. 



As discussed, every reference to infontiation or change of 
authorization should go through the reference monitor. Thus, all 
commands issued by a user or other subject $re monitored by the 
reference monitor. This approach is particulkrly useful in multiuser 
computer environments. 



The totality of the protection mechanisms within a computer 
system ~ including hardware, software, and ^ware, the combination of 
which is responsible for enforcing a security irolicy ~ is commonly 
•known as a "trusted computing base" (TCB). : If the trusted software is 



1 designed to be as simple as possible, for the sake of verifying the 

i 

2 reference monitor, then the trusted software | is known as a "security 

3 kemer. 
4 

5 Generally, TCBs attempt to meet the j control objectives set out in 

6 the Orange Book. Compliance with these ofjjectives inspires user 

7 confidence, and increases the overall desirab^ty of a computer system. 

8 These objectives deal with: 
9 

Q 10 (1) security policy; 

yi 11 (2) accountability; and 

U1 12 (3) assurance. 

m \3 

I 14 The security policy objective entails eiiforcement by the TCB of 

15 the desired security rules- These security rules are designed to limit the 

% 16 access to and dissemination of information in a precisely defined 

^'17 manner. 
18 

19 Security policies may include provisions for the enforcement of 

20 both mandatory and discretionary access control rules. Mandatory 

21 access control rules control access based directly on comparisons of the 

22 user's security level and the sensitivity level (|)f the Information being 

23 sought. Discretionary access rules control arid limit access to identified 

24 ' individuals who have been determined to have a need-to-know. 

4 



1 

2 These access control rules call for associating with each user 

3 identification code a statement indicating the user's access rights. This 

4 statement often includes information representing the user's security level 

5 (for mandatory control purposes), and membership in groups (for 

6 discretionary control purposes)* 
7 

8 The accountability objective calls for providing each user with an 

9 individual user identification code (often called a "user name") and for 

10 the TCB to be able to recognize the code ensure that it is being 

11 used by its proper user. This may be donej by checking the user's 

12 password. This ensuring the user's identity lis known as "authentication." 
3 

14 In addition, the accountability requirement calls for the existence 

15 of auditing capabilities. Such capabilities alow for the auditing of 

16 actions which can cause access to, generation of, or release of classified 

17 or sensitive informatioiL 
18 

19 1.4 Assurance Objectives and Trusted" Systems 
20 

21 Hie assurance objective is especial^ important in the present 

22 context That objective is concerned with tiking steps to ensure that the 

23 security policy is correctly implemented and! that the TCB accurately 

24 ' mediates and enforces the intent of that policy. Steps may be taken to 

5 



insure that each portion of the TCB is assured. To accomplish this 
objective, two types of assurance are needed. 

The first type of assurance is life-cycle assurance. This type of 
assurance refers to steps taken to ensure that the computer system is 
designed, developed, and maintained using iformalized and rigorous 
control standards. 



The second type of assurance is opeirational assurance. 
Operational assurance deals with the features and system architecture 
used to ensure that the security policy is uiicircumventably enforced 
during system operation. All of the softwake (sometimes referred to 
informally in the art as "code") in the TCB is generally analyzed to 
determine the assurance level of the systetn. 

As the amount of code in the TCB increases, it becomes more 
difficult to ensure that the TCB accurately i enforces the security policy. 
Because of this, it is desirable to minimi?^! the amount of trusted code, 
and thus the conq)lexity of the TCB. 

A TCB is usually operated with a substantial amount of software, 
such as text editors and other applications,! operating within the security 
policy of the TCB. Generally, this untrusted software asks the TCB for 
access to objects when the user or the untriisted software requires them. 



Thus, the majority of user's requests to the TCB, and the majority of the 

i 

information that a user obtains from the TC^, are handled through the 
agency of untrusted software. 

This untrusted software, however, is by nature in danger of 
compromise and vulnerable to bugs. For so^ne types of requests and 
displays, malicious or malfunctioning untrust4d software could 
compromise the enforcement of the security ipolicy. Generally, TCBs 
cannot distinguish between requests faithfully made by the untrusted 
software on command from a user and eithe^ requests made by the 
untrusted software at its own initiative or requests that misrepresent the 
user's actual command. For example, if conimands issued by an 
authorized user to change certain users' secu^ty levels were made 
through the agency of untrusted software, iti would be possible for 
malicious or malfunctioning untrusted softw^e to inappropriately raise 
the security level of a user. Such inapproprike raising of a security 
level could result in the disclosure of sensitive information. 

Furthermore, TCBs generally cannot ensure that displays made by 
untrusted software are faithful. This poses problems in that if displays 
of audit records were made through the use ^f untrusted software it 
would be possible for malicious untrusted software to misrepresent these 
audit records to hide suspicious activities. 



To overcome these problems, prior-art systems have developed a ^ 
concept known as a "trusted path." A trusteb path is a mechanism by 
which the user can communicate directly witti the TCB. A trusted path 
may only be activated by the user or the TcIb and cannot be imitated 
by untrusted code. Such a trusted path is a i positive TCB-to-user 

connection that bypasses all untrusted softwa|re. The Orange Book 

I 

requires a trusted path for all systems to hale a security rank of B2 or 
above. 

A "trusted command" (also known as trusted-path command) is 
a command which requires a trusted path between the user and the TCB 
for execution. The specific security policy ot a computer system will 
determine which commands are defined as t^ted commands. For 
example, commands relating to changes of tike security levels of users 
would be trusted commands. 

1.5 Paners as Increasers of Sys tem Comjilexity 

Because of perceived performance problems, prior-art computer 
systems often included code to implement certain functions in the TCB. 
One such function comprises a portion of cckie known as the "parser." 

The parser performs the basic interpretation of user commands by 
• translating a human-readable representation iof a user conmiand (e.g., a 

8 



command typed by a user at a keyboard) into a machine-readable 
representation known as the binary representation, or the parsed 
command. A user command may consist of |a group of words, typed by 
the user, specifying some action to be takenJ The user command may 
also specify one or more variations or options of that action. 

For the convenience of the user, most parsers allow these option 
words to be typed in any order without chaiiging the meaning of the 
user command. Also, most parsers allow the user to type the words in 
either fiiU or abbreviated form. In some instances, several possible 
abbreviations exist. Further, in most parsers; the user may vary the 
spacing between the words without changing i the meaning of the 
command. Some parsers also check user coinmands for proper syntax, 
and report errors to the user prior to execution of the command* Other 
parsers prompt the user for missing information, avoiding the need to 
completely retype an incomplete command. 

Thus, several different inputted human-readable representations 
may be associated with each unique parsed command. It is the job of 
the parser to translate accurately these inputted representations of user 
commands (which may vary with each user) into specific parsed 
command representations. Due to the complex nature of parsing, large 
amounts of computer code are generally ass^ated with this activity. 



1 Prior-art trusted software systems have included the parser for ^ 

2 trusted commands, and thus the associated code, within the TCB. In 

3 these systems every trusted command was p^sed and executed 

4 exclusively by trusted code. The inclusion c^f the parsing code in the 

! 

5 TCB was regarded as necessary for proper ^stem operation. 
6 

7 As discussed above, however, the ease and degree of assuring a 

8 system is roughly inversely proportional to tjie complexity of the system's 

9 TCB. Thus, the inclusion of the parser in ^e TCB results in more 

10 complex assurance analysis and a corresponding decrease in system 

11 confidence. Prior art devices (since they needed to be small and simple 

12 to support assurance) have thereby inherency constrained the user- 
's friendliness of computer systems. 

14 

15 2. SUMMARY OF THE INVENTION 

16 

17 The present invention provides a nuriibcr of advantages over the 

18 prior art By reducing the complexity of the! TCB, the amount of trusted 

19 code that must be verified or assured is reduced. In addition, the 

20 general usability of the system is increased, because the improved 

21 method of processing trusted conmiands allows for the implementation of 

22 added computing functions at little or no additional cost in TCB 

23 assurance. 
24 

10 



1 The present invention includes an improved method for the ^ 

2 execution of trusted commands. In this improved method, the required 

3 steps for processing a trusted command are split between trusted and 

4 untrusted code. In this manner the amoun^ of trusted code in the TCB 

5 may be significantly reduced. 
6 

7 As discussed above, the parsing of a command can be compara- 

8 tively difficult, and often requires large amounts of complex code. 

9 However, it is relatively simple to translate |the parsed representation of 

10 a command into a standard human-readablci representation for display to 

11 the user. This is in part because a single, standard human-readable 

12 display representation may be associated with each parsed representation. 
3 The present invention takes advantage of tijis fact by parsing the trusted 

14 commands in untrusted code prior to execujtion in the TCB. 
15 

16 In general, the present invention inclWes a computer system 

17 which includes a TCB operating as a reference monitor. Included in the 

18 TCB is the security-relevant code necessary for the actual execution of a 

19 trusted command. 
20 

21 Associated with the TCB are one or more untrusted subjects (e.g. 

22 processes). Each such subject has particular' access rights, which may 

23 include a security level. These untrusted siibjccts communicate only with 

24 ■ the involvement of the TCB. The TCB allbws communication only as 

11 



permitted by the system's security policy. Each untrusted subject is 
substantially independent. 

In each of these untrusted subjects, uhtrusted software is generally 
run. This untrusted software may include am untrusted operating system 
(UOS), and generally includes applications such as text editors. In the 
present invention, the untrusted code includes the non-security relevant 
functions necessary for the execution of a tniisted command. 

Attached to the computer system are several user terminals. 
These user terminals allow the user to exch^ge information with the 
computer system. All terminal activity is sein first by the TCB. A 
secure-attention key is dedicated for use on ieach terminal attached to 
the computer system. The TCB is designed! to recognize and trap this 
key signal. Activation of this key by the user establishes a trusted path 
between the user terminal and the TCB. Alternate methods for 
establishing a trusted path may be utilized. 

The TCB is generally provided with a limited number of 
"direct" user commands (direct commands). Because of this, the majority 
of the user's activities will take place in the untrusted operating system. 

While operating in the UOS, the user may attempt to execute a 
' trusted command. When one of these commands is issued by the user, 

12 



1 the untnisted code in the UOS checks the syntax of the command and ^ 

2 may prompt for missing parameters; then the untrusted parser converts 

3 the command into a parsed representation that will be referred to here 

4 for convenience as the 'T^inaiy representation," In some instances, 

5 command procedures and application-issuec^ trusted commands will also 

6 be parsed and translated into a binary representation, 
7 

8 This binary representation is then passed from the UOS to the 

9 TCB. The TCB initially associates the bin^ representation with a 

10 physical terminal, and copies the binary ref^resentation into a memory 

11 buffer assigned to that terminal, 
12 

3 Once this has been completed, the Untrusted code in the UOS 

14 may prompt the user to activate the secure-attention key. If this key is 

15 activated, a trusted path will be established! between the user terminal 

16 and the TCB. Alternate methods may be employed to initiate this 

17 trusted path, A randomly generated proce^ ED, which may be 

18 generated at login, may be utilized to prevent untrusted code from 

19 simulating a trusted path, 
20 

21 Subsequent activity by the TCB depends on the type of command 

22 that is represented by the binary representation. If the command is one 

23 that will not modify any information, i.e., a request to view information, 

24 ' the TCB verifies that the user has the necessary access rights, and 

13 



1 attempts to execute the binary representation. A human-readable 

2 standard representation of the binary command received by the TCB is 

3 displayed along with the information. 
4 

5 In most instances, if the command requested by the user requests 

6 modification of information, the TCB display^ for confirmation a 

7 standard human-readable form of the conmisind, along with an indication 

8 of what the result of command execution will be. The user is then 

9 requested to confirm (by typing a response via the trusted path) that the 
rj 10 displayed command was received correctly a4d should be executed. 

111 ' 

01 12 This confirmation allows the user to ensure that untrusted code 
or 3 has not performed an unauthorized modification of the user's original 
1 14 command. Also, confirmation allows for thej detection by the user of 
^15 any errors that may have occurred during thi parsing process. In 

If 16 situations where the binary representation represents a command 

"17 procedure or an application-issued trusted command, the confirmation 

18 ensures that the command proposed by the ilintrustcd software is 

19 acceptable to the user. 
20 

21 If the command is confirmed by the user, the TCB checks to 

22 ensure that the user has the necessary access rights to execute the 

23 command and, if so, attempts to execute the! command, 
24 

14 



1 A distinct advantage of the present iitivention arises from the fact ^ 

2 that the execution of a trusted command is | split between trusted code 

3 and untrusted code. The actual parsing of the command occurs in 

4 untrusted code. The trusted code included in the TCB checks the 

5 parsed command for correctness and displays it to the user in human 

6 readable form. This checking and display pf a parsed command requires 

7 substantially less code than is required to p^se a command. 
8 

9 Thus, since the command parser is included in the untrusted code, 

10 the amount of trusted code in the TCB is iWimized. This lowers the 

11 difficulty of trusted system assurance, and increases the amount of 

12 confidence that may be placed in a system. 
3 

14 It is a further advantage of this inveijition that the user interface 

15 is separate from the underlying functions performed by the TCB. This 

16 allows for implementation of alternate UOS-to-user interfaces without 

17 major modification of the TCB. Further, tl^e amount of time and effort 

18 to develop such a command interface is reduced. A still further 

19 advantage is that more useability features may be provided without 

20 substantially increasing the complexity of th^ TCB. Examples of such 

21 useability features are command line editing and recall. 
22 
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1 3. BRIEF DHSCRIFnON IQF THR DRAWINGS 

2 i 

3 Figure 1 illustrates the various levels jwithin a computer system; 
4 

5 Figure 2 illustrates various layers within the trusted computing 

6 base; 
7 

8 Figure 3 illustrates a trusted path; 

9 

10 Figures 4A and 4B are flow diagrams representing a method for 

11 processing trusted commands. Differences ih box representation in these 

12 drawings is explained below. 
3 

14 Figure 5 illustrates one method of implementing the invention; 

15 

16 Figure 6 is a flow diagram representing a method for verifying a 

17 trusted path; 
18 

19 Figure 7 is a state transition diagram of a further embodiment 

20 utilizing various command states. 

21 
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4. DESCRIPTION OF SPFCIHg: EMBODIMENTS 

i 

A specific embodiment of the present invention is described with 
respect to a computer which supports varioijs user processes and may 
operate in a multiuser environment. As an illustration, an 
implementation in connection with a VAX model computer, available 
from Digital Equipment Corporation (DEC)i is briefly described. It 
should be understood that the present invention may be readily applied 
to various types of computer systems includibg PC networks, stand-alone 
multiuser computer systems, or single user computer systems, to name a 
few examples. 

4.1 Overview of Software Architftrtiir^ 

FIG.l illustrates a preferred computing environment which is 
generally designated by the reference numeijal 2. A trusted computing 
base (TCB) 10 resides at the center of the computer system. The TCB 
10 acts as a reference monitor in that accesjs to information is mediated 
by the TCB 10. 

In a general embodiment of the invention, the TCB 10 may be a 
secure kernel residing under the general operating system of a computer 
system. In one embodiment, the TCB 10 comprises trusted code 
residing underneath a VMS or Ultrix system. 

17 



The TCB 10 enforces a security policjy which identifies permissible 

modes of access between users or computer! processes (subjects) and 

j 

files, memory segments or other objects. Access to stored information is 
mediated by the TCB 10, so that the TCB 10 may determine whether a 
particular user or untrusted subject can accejss particular information- In 
order for the TCB 10 to fulfill its protective function, it must take into 
account the three requirements discussed al^ve: (1) completeness, (2) 
isolation, and (3) verifiability, 

A more complete understanding of the TCB 10 may be obtained 
by reference to FIG.2. As is illustrated, the TCB 10 may comprise 
several distinct layers. Each layer of the TCB 10 comprises trusted 
code. This trusted status is indicated by the security boundary 11. In 
one embodiment, layers of particular interest are the layers to be 
referred to as: secure server (SSVR) 12, Copimand Conveyor (CC) 14, 
and VTerm (VT) 16. 



The TCB 10 includes the trusted cod^ necessary to ensure 
compliance with the Orange Book requirements. In alternate 
embodiments, the trusted code may ensure compliance with different 
systems of security requirements. The TCB; 10 also includes the code 
which actually executes the requested trusted command, as discussed 
below. 

18 
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2 Each untrusted subject is generally suii)ported by an untrusted 

3 process. This process may spend time in on^ of two "modes." The first 

4 mode, in which the process usually runs, is Idnown as a "user mode." 

5 This mode is a restricted hardware state such as the VAX user mode 

6 that is known in the art. This process may also spend time executing 

7 trusted code in an all-powerful hardware sta^e. This state is represented 

8 by the VAX "kernel mode", which is known iin the art. This state may 

9 be triggered by a request by the untrusted sjibject of the security kernel 

10 Such a request may be made in a conventioiial manner and is commonly 

11 called a "kernel call." This mode may also \)e triggered by asynchronous 

12 events (e.g. the completion of an Input/Output request previously made 
3 by the untrusted subject). i 

14 

15 In one embodiment, the TCB 10 alsoi has one process associated 

16 with each terminal that commimicates with the user over the trusted 

17 path. This process is known in the art as a|a "execution thread." In this 

18 embodiment, each execution thread shares its address space with other 

19 TCB execution threads. An advantage of si^ch sharing is economy of 

20 machine resources. Full-blown processes, e^ch with its own address 

21 space, would require far more machine resojurces than if such address 

22 space sharing is employed. 
23 
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It is the CC 14 which provides the interprocess communication 
for passing parsed commands between the pijocesses that support the 
untrusted subjects, and the processes within the TCB 10 that support the 
trusted path. 

The untrusted code may submit to th^ TCB 10 the parsed 
representation of the trusted command by making a kernel call. The 
kernel call causes the process supporting thej untrusted subject to switch 

to the all-powerful hardware state and to be^n to execute trusted code 

j 

designed to handle kernel calls. This trusted code recognizes the nature 
of the kernel call and calls the CC 14. The| CC 14 then obtains and 
copies the binary representation of the trusted command into protected 
memory and puts it in a global data structure that supports the user 
process associated with the terminal in ques^ioiL 

The VT 16 layer includes the trusted code which monitors all 
terminal activity and checks for activation of the secure-attention key. 
In one particular embodiment, the VT 16 layer also includes code which 
tracks which physical terminal is associated With a particular user or 
untrusted subject 



The specific maimer of implementation of the above described 
activities will be apparent to one skilled in the art having the benefit of 
' this disclosure. I 
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Referring to FIGS 1 and 3, "around" tk TCB 10 is a general 
untrusted operating system (UOS) 20. The l|OS 20 generally comprises 
mitrusted code and may include a traditional I operating system such as 
Ultrix or VMS. Alternate constructions are envisioned where the UOS 
20 includes any untrusted code. It will be appreciated that the system 
may include untrusted code that is separate from TCB 10 and UOS 20. 

Most user activity will occur in the U<f)S 20. In one embodiment, 
a specific UOS 20 may run in each untrusted subject. 

4.2 User Terminals and the Seciire-Attentton Kev 



Associated with the computer system are one or more user 
terminals 30. These terminals 30 may be conventional in construction, 
in that they allow the user to exchange infoijmation with the computer 
system. Either "intelligent" or "dumb" terminals may be used. Examples 
of such dumb terminals are the well-known VT scries 200 and 300 
terminals. These terminals are available firopi Digital Equipment 
Corporation or its authorized dealers. ' 



A particularly useful terminal includes control programming that is 
designed with security features in mind, such as is described in a co- 
pending U.S. patent application entitled "Method for Securing Terminal 



1 and Terminal Apparatus for Use with the Mejthod," Serial No. 456,672, ^ ' 

2 filed by Wei-Ming Hu, Clifford E. Kahn, Ancjrew H. Mason, and Peter 

3 A. Sichel on December 26, 1989 and to be commonly assigned with this 

4 application, 
5 

6 A keyboard is attached to each user terminal. Each keyboard 

7 includes a key employed as a secure-attention key. This key is utilized 

8 to establish a trusted path between a user tehninal and the TCB 10. In 

9 one embodiment, the secure-attention key is pn "out-of-band key" for the 
a 10 UOS 20. It is desirable that the signal sent by the terminal upon 

y1 11 activation of the secure-attention key is generally not utilized by the 

Uh2 applications running in the UOS 20. An ou^-of-band key is convenient 

^{f 3 since it does not restrict the traditional number of user keys and the 

Li4 signal is sent immediately, even if other I/O i is pending. For example, 

JjJlS the secure-attention key may be the BREAK key on the terminal 

516 keyboard. 
17 

18 In many terminals (such as the VT 2pC and VT 3XX families) 

19 locking of the keyboard prevents the transmission of several key signals. 

20 In these terminals, however, the BREAK ke^ signal may be transmitted, 

21 even from a locked keyboard. Thus it is generally desirable to employ 

22 the BREAK key as the secure-attention keyi Also, the signal generated 

23 by activation of the BREAK key comes in ahead of other characters in 

24 • the keyboard buffer. A further advantage df utilizing the BREAK key is 

22 



1 that software running in the UOS 20 cannot | get the terminal to send 

2 that character. 
3 

4 4.3 The Trusted Path and Direct Commands 
5 

6 The TCB 10 generally operates as a reference monitor. 

7 

8 Upon initial login or at other times wfhen the user is not 

9 connected to a process in the UOS 20 (e.g.,! an application program), the 

10 TCB 10 responds to a comparatively limitedj series of "direct commands," 

11 which may include a CONNECT command to connect to an untrusted 

12 subject When the user is connected to such an untrusted subject, the 

3 TCB 10 checks for the secure-attention signkl; if a signal other than the 

14 secure-attention signal is received, the TCB |10 passes the signal to the 

15 connected untrusted subject. 
16 

17 As discussed above, in one specific ejnbodiment the trusted code 

18 in the VT layer 16 monitors all terminal activity. When the code in the 

19 VT 16 notices that the BREAK key has be^n depressed, the SSVR is 

20 signaled in a conventional manner (such asiby advancing an event count 

21 or activating a flag). Code in the SSVR 12 recognizes this signaling and 

22 establishes a trusted path between the user I terminal and itself. In this 

23 manner, the secure-attention key signal is trapped by the TCB 10. 

24 ' • I 
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1 In certain security environments, general security requirements 

2 mandate that the TCB 10 make displays wh^n a trusted path is 

3 established and exited by the user. In one Embodiment, when a trusted 

4 path is established, the TCB 10 sends a reset command sequence to the 

5 physical user terminal 30 to assure that it is I in a known state. This is 

6 done in part to ensure that the information Idisplayed to the user by the 

7 TCB 10 is in the intended form, (e.g., corrett font). A particularly 

8 useful sequence of commands to implement the reset command sequence 

9 is described in the aforementioned copendii^g U.S. patent application by 
10 Hu et at. 

11 

12 When the secure-attention key is aai^ated, other than in 

3 connection with the issuance of a trusted cpmmand, the secure server 12 

14 displays a particular banner and prompt (for example: "SSVR>" together 

15 with the user's process identifier, discussed below), to indicate that the 

16 user is conversing interactively with trusted I code. If the secure-attention 

I 

17 key was activated in connection with the issuance of a trusted command, 

18 the secure server 12 displays to the user sopa.t indication of what is to 

19 be done, as discussed below. 
20 

21 When command execution is complete, or when the user 

22 establishes or reactivates a session with th4 UOS 20, the TCB 10 issues 

23 a message to inform the user that he/she is breaking the trusted path. 

24 When a session with the TCB is complete^ the memory in the physical 
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1 terminal may be cleared by the TCB. Hiis is done to protect trusted 

2 information from both untrusted code and uiiclassified persons who may 

3 later use the terminal. A particularly advantjageous method of clearing 

4 the terminal memory is described in the afoijementioned co-pending 

5 patent application. 
6 

• 7 The nmnber of direct user commands: available from the TCB 10 

8 is preferably limited to reduce the complexitjy of the TCB 10. Generally, 

9 a command is dirert if: 
10 

11 a, one needs the comn^and when one 

12 is not coimected to an untrusted subject; 
3 

14 b. end users depend oii the com- 

15 mand's correct behavior for sc<nirity (e.g., 

16 LOGOUT); or 

17 I 

18 c. the conunand must he issued when 

19 no user process in the UOS 2i) is running. 
20 

21 In most cases, the user will converse with the TCB 10 through the 

22 SSVR 12. In one embodiment the user conversing with the SSVR 12 

23 may be restricted to commands which alloW him/her to establish 

24 ■ (connect) or end (discoimect) a computing isession in the general UOS 

25 



1 20. Further commjinds may be added, such ?is allowing the user to view " 

2 the existing UOS 20 sessions or change his o^ her password, but it is 

3 generally desirable to limit the number of avlailable commands in the 

4 TCB 10. It is further desirable to ensure siciiplicity in the syntax of 

5 these direct commands. 
6 

7 The simple syntax of the direct commtods, and the comparatively 

8 small amounts of code necessary to interpret! these commands, do not 

9 substantially increase the complexity of the 'tCB 10. 
10 

11 4.4 Login Processing by the TCB 
12 

3 To initiate a computing session in the illustrative UOS 20, the 

14 user may first login to the computing envirojiment through the SSVR 12. 

15 To initiate a login, the user activates the secure-attention key (or 

16 performs some other action to gain the attention of the SSVR 12). As 

17 discussed above, this establishes a trusted ps.th between the user terminal 

18 and the TCB 10. -Mtemate embodiments ate envisioned wherein other 

19 methods are employed to establish a trusted path. 

20 I 

21 Once a trusted path has been establiihed, the SSVR 12 prompts 

22 the user for his/her specific user name and password. The various 

23 layers in the TCB 10 perform well-known security checks to ensure that 

24 ' the user has the necessary access rights to login at the terminal. If the 
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user possesses the required access rights, a computing session is 
established in the SSVR 12. 

At this time, the user's security inforriiation is stored by the TCB 
10. The TCB 10 also stores in memory a u[nique identifier of the user 
process. This information is maintained in tnemory by the TCB 10 as 
long as the user has an active session. 



4.5 Connection to Untrusted Process 



Because the number of direct user commands in the TCB 10 is 
preferably limited, the user will generally choose to establish a 
computing session with an untrusted subject Such an untrusted subject 
may include appli<::ation programs residing in the UOS 20. 



In one specific embodiment, when the user establishes a 
computing session in the UOS 20, the user's physical terminal 30 is 
associated with a virtual terminal of the UOS, The user converses with 
the untrusted subject through a computing session within the UOS 20. 
When such a connection with an untrusted subject is made, the VT layer 
16 of the TCB 10 stores in rnemory which physical terminal 30 is 
associated with which virtual terminal in ^n untrusted subject In this 
manner, trusted commands received from 

attributed to the actual user at the physic^ terminal 30. Once the user 
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an untrusted subject may be 



has established a computing session within t^e UOS 20, normal 
computing activities may be carried out. 

A more detailed understanding of thejse activities may be obtained 
through reference to FIG.4A and 4B. Activities indicated by heavily 
bordered blocks are performed by the TCB llO, or trusted code. 
Activities represented by lightly bordered blocks are performed by 
untrusted code. 



In FIG.4A, the user terminal is represented as having established 

I 

a computing session 100 within the general |UOS 20. EXiring the session, 
the user may attempt to execute various coijnmands. Utilities within the 
UOS 20 determine whether the issued comi|nands are trusted commands 
50. If the command is not identified by Xht UOS 20 as a trusted 
command, the UOS 20 attempts to perform the command at process 60. 
In these cases the operation and existence of the TCB 10 may have little 
effect on the command's behavior as seen l>y the user. 

4.6 The Process Identifier 

In one embodiment, a process identifier (process ID) is associated 
with each user process at the time of loginl This process ID is a 
pseudo-randomly generated alpha-numeric tag which is associated with 
the user throughout his/her computing session. 
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1 The process ID is useful if the untrusted code can temporarily 

2 disable or delay the effect of activation of th|e secure-attention key. For 

3 example, untrusted code can send a reset command to some terminals, 

4 While these terminals are resetting, activatio^ of the secure-attention key 

5 has no effect. Such a technique may allow ^intrusted code to trick the 

6 user into thinking a trusted path had been established when it had not 

7 been. The process ID inhibits such trickery; by allowing the user to 

8 distinguish between actual and emulated trusted paths, 
9 

10 When the user first logs in, he/she vfiill not yet know the process 

11 ID and cannot detect a false trusted path, iHowever, to simulate a login 

12 dialogue, untrusted code would have to gue^ when the user activated 
3 the secure-attention key, or somehow detect the activation of the key 

14 even though the TCB could not detect it, puessing the activation time 

15 is impracticable, because users start login dialogues at their own 

16 convenience and give no advance signal to ithe TCB prior to activation 

17 of the secure-attention key. Detecting the secure-attention key even 

18 though the TCB could not detect it would |be possible only by causing 

19 the key to yield a signal different than the| TCB expects. Methods to 

20 prevent such an event are described in th^ co-pending application by Hu 

21 et al,, referenced above. 
22 

23 With some terminals, the untrusted I code may be able to program 

24 -the terminal so that the secure-attention key generates a signal that is 
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1 recognizable to the untrusted code, but not tb the TCB. In these cases, 

2 generation of the process ID at the time of login would be 

3 unsatisfactory. Instead, the process ID may be generated prior to user 

4 login. For example, in these embodiments, tke process ID may be 

5 generated when the user is registered with the TCB 10 and stored in 

6 protected memory. In this embodiment the iiser may be given a way of 

7 changing his/her process ID, just as the userj can generally change their 

8 password, 
9 

r J 10 In one particular embodiment, when the user logs in the SSVR 12 
IJI 11 pseudo-randomly generates a process ID and assigns this ID to the 
yi 12 specific user at the physical terminal. MethcMs of generating pseudo- 
Oil 3 random identifiers are generally known in th^ art. In one embodiment, 
^ 14 the random number initial seed is based on la hardware (as opposed to a 
2^ 15 software) event. Ttie algorithm for generatijiig successive random 

16 numbers should be computationally difficult to invert, 
°17 

18 This process ID is maintained in the TCB and is never provided 

19 to untrusted code. Thus, untrusted code in the general UOS 20 is 

20 prevented from discovering the specific process ID assigned to the user. 
21 

22 The user is responsible for noting and retaining his/her assigned 

23 process ID. To promote user retention the | process ID may be 

24 ' generated as a pronounceable group of chanacters. Methods for such 
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generating pronounceable passwords are described in "A Random Word 



Generator", MTTRE Technical Report (MTR 
Morrie Gasser. 



3006), May, 1975, by 



The process IDD is displayed to the user when a trusted path is 
established between the user terminal and th^ SSVR 12. Displaying the 

ID serves a useful security function as it inhibits untrusted code from 

I 

"spoofing" the user. Absent the process ID ^ may be possible for an 
untrusted subject to emulate the SSVR 12. An untrusted subject, 
emulating the SSVR 12, may be able to trick the user into divulging 
security-relevant information or otherwise cotnpromising system security. 

i 

The process QD, known only to the usjer and the SSVR 12, 

I 

inhibits this type of "spoofing." Before the ijser responds to an apparent 
SSVR 12 request, he/she will first verify ths^ the proper process ED is 
displayed. Since the process ID is known b^ only the user and the 

j 

SSVR 12, it is extremely difficult for an untbsted subject, ignorant of 
the process ID, to fool the user into believiig that he/she is conversing 
with the SSVR 12. 

i 

FIG.6 illustrates a flow diagram of tliis process. When the user 
initially logs into the computer system throu^ the SSVR 12, a randomly 
generated process ID is assigned to the useir. This activity is represented 
by process 310. In one embodiment, this pjrocess ID comprises 



1 alphabetic characters and is pronounceable. The pronounceable nature 

2 promotes user retention of the ID, The prof:ess ID is then stored in 

3 trusted memory by the SSVR 12 and displayed to the user by the SSVR 

i 

4 12 at process 320. I 
5 

6 During the course of the computing session, the TCB determines 

7 if the user is operating through a trusted path. This activity occurs at 

8 process 330. If the TCB determines that a trusted path is not 

9 established, the process ID will not be displayed to the user. This is 
10 noted at process 350. 

11 

12 The process ID is maintained in trusted code and memory, and is 

i 

3 inaccessible to untrusted subjects. Each tim^ a trusted path is 

14 established between the SSVR 12 and the user, the SSVR 12 displays 

15 the user's process ID at process 340. By observing the displayed ID, the 

16 user is assured that an actual trusted path l^as been established. 

17 I 

18 4.7 The Command Convevnr 

19 As discussed above, the conmiand coiaveyor (CC) 14 is a layer in 

20 the TCB 10 which comprises part of the trusted code. The CC 14 is 

21 utilized to ensure proper communication of trusted commands between 

22 the SSVR 12 and the process supporting thi untrusted subject. As 

23 discussed, such an untrusted subject may inc^lude a UOS 20. 

24 ' ' I 
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Associated with each physical terminal 30 is a command buffer. ^ 
In some embodiments, a status code may be ^sociated with each 
terminal. In a still other embodiments, one 6f five command states is 
also associated with each physical terminal. The command buffer is 
used to store the binary representation of th^ trusted command. The 

status code may be employed to provide the jresulting execution status to 

I 

the untnisted subject. The command states generally comprise five 
possibilities: 

(a) no command, 

(b) command submitted, I 

(c) command in progress^ 

(d) ignore finish, and | 

(e) command done. 

These states are used to indicate the various states that may be 
encountered in the execution of a trusted command. FIG. 7 is state 
transition of the command states. A detaileki explanation of these states 

and the statuses may be obtained from the following discussion. 

i 

4.8 Distribution of Processing of Trusted irnmmands 



As discussed above, the TCB 10 "recognizes" two categories of 
commands. For the purposes of this specifixation "commands" include 

33 



1 user instructions received through the use ofi command line interfaces, 

2 menu interfaces, direct manipulation interfaces or the like. 
3 

i 

4 The first category includes "direct contmiands" issued while the 

5 user is operating in the SSVR 12 layer of tl^e TCB 10, i.e., is 

6 interactively conversing with the TCB 10. As discussed above, it is 

7 desirable to limit the number of direct conutnands available to the usen 

8 The execution and processing of these direcjt commands is carried out 

9 using traditional methods known in the art, 
10 

11 The second category includes "trusted commands," These 

12 commands are issued by a user operating ii a non-trusted computing 

3 environment, such as in the general UOS 20. In one embodiment these 

14 trusted commands are issued by a user operating in an untrusted virtual 

15 machine. FIGS.4A and 4B illustrate the acktivity necessary to execute 

16 such a command. 

18 If the user attempts to execute a tn^ted command, the parser 

19 residing in the general UOS 20 parses the | trusted command string and 

20 converts it into a binary representation at jprocess 70. In parsing the 

21 command, the untrusted code in the UOS 1 20 checks syntax and 

22 semantics, and prompts for missing param<kters. Parsing strategies are 

23 well known in the art and will not be discussed herein. 

24 • • 
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From a se<nirity perspective, it is not required that the code in the' 
UOS 20 perform an accurate translation of the user's commands into a 
parsed representation (binary representation)* The confirmation 
mechanism, described below, is designed toi catch such errors whether 
benign or malevolent. 

Following parsing of the command, a process supporting the UOS 
20 issues a call to the TCB, submitting to the TCB the identification of 
the terminal from which such command wa$ issued, at process 80. In 
one embodiment, the virtual terminal from Iwhich the command was 
issued is submitted to the TCB. Such a ca^ is processed by the CC 14 
in the TCB 10. The CC 14 then determines which trusted subject 
submitted the command and copies the parsed representation into 
protected memory at process 90. In one er^bodiment this determination 
is made by asking VTerm to identify the physical terminal associated 
with the UOS's virtual terminal. 



Such a submission of the binary representation will be successful 
only if the TCB 10 determines that the subjnitting terminal is connected 
to an active process. 

Normally, in embodiments utilizing the command states, the 
command state of the submitting physical terminal is no command which 
indicates that there is no trusted command submitted by that physical 



terminal or in progress. This state is represented by state 400 in FIG. 7. 
When the state is no command, the CC 14 j saves the binary 
representation in the command buffer, and bets the physical terminal's 
state to command submitt^H, represented bjf transition state 410. 
Otherwise, the submission fails. 

When the untnisted subject running m untnisted code receives 
indication from the TCB 10 that the comm^d has been submitted, it 
requests the user to activate the secure-attejition key. In one 
embodiment, the untnisted code in the UO^ 20 will request that the 
user activate the BREAK key. | 

If the user activates a cancellation k^y, for example Ctrl-Y or 
Ctrl-C, instead of activating the secure-attention key, code in the general 
UOS 20 may cancel the trusted command. This can be accomplished by 
the untnisted code issuing a kernel call (i.e.^ a request by the untnisted 
subject of the security kernel) and informing the CC 14 that the 
command is to be aborted. If the CC 14 fipds that the command has 
not been sent to the SSVR 12, the commaiid is canceled. Similarly, if 
the user process in the UOS 20 is killed, thb process rundown code may 
cancel the tnisted command request HoweVer, if the CC 14 finds that 
the command has jdready been sent it proceeds; because the user is 
already executing tlie command. 



In embodiments employing command "states, cancellation of the 
trusted command request results in the comi^and state being changed 
from command submitted to no command . iThis process is indicated in 
FIG. 7. 

If the user attempts to establish a trusted path at the same time 
the trusted command is sent to the TCB 10,| then the TCB 10 must 
arbitrate; either of these requests may be processed first. If the secure- 
attention signal is processed first, the TCB 10 may defer the command 
submission, and a connection with the SSYR^ 12 is established. If the 
submission is processed first, then the user ^ees the confirmation screen 
as is described below. 

If, when prompted, the user activates I the secure-attention key, a 
trusted path is established between the useri physical terminal 30 and 
the SSVR 12 in the TCB 10. This configur^on is Ulustrated by the 
dark line in FTG3, When the VT layer 16 jdetects the secure-attention 
(BREAK) key, it notifies the SSVR 12 whic^ then establishes a trusted 
path in the trusted path-supporting process Associated with the user's 
physical terminal 30* 

Once the trusted path is established, the TCB 10 maintains 
exclusive control over the physical terminal 30. In one embodiment, 
untrusted code in the UOS 20 waits to be ifotified that the command 
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has been completed. Thus, the user essentially bypasses the untrusted ■ 

code, and converses only with trusted code, i Thus, if the user's process 

i 

in the general UOS 20 is killed, or the user'^ process terminates, or the 
general UOS 20 crashes, the trusted command may still be executed. 
The user will not be informed of any of the^e activities until the trusted 
command has been completed or abandoned!. 

Following establishment of the trusted path, the security 
requirements of the system require interacticin between the user and the 
SSVR 12. This is necessary to execute comjnands which require the 
establishment of a trusted path. The Orang^ Book criteria, and/or the 



system's security goals, will determine which 



commands require this 



interaction as is generally discussed in Section 4.9 below. 

The establishment of a trusted path ih these instances is useful 
for several reasons. First, it allows the secui-e server to identify the 
specific user issuing the command. Second, jthe trusted path allows the 
user to review and approve (or reject) the rjcquested action in a trusted 
fashion. This reduces the possibility of malicious untrusted software 
altering a command request, and allows for khe detection of parsing 
errors. 



FIG.4B illustrates the activity occurriilg after control has passed to 
the TCB 10. As discussed above, the TCB 10 first establishes a trusted 

38 



path at process 120. The TCB then checksl to see if a trusted command^ 
has been submitted by the usen Untrustedj code may then wait for the 
command to finish.. 



Once a trusted path has been established, the SSVR 12 will call 
the CC 14 to return the binary representation at process 130. In one 
embodiment, the CC 14 will first determin^ the conamand state of the 
physical user terminal 30. In a still furtherj embodiment if the command 

state is command submitted 410 (FIG. 7), Jhe CC 14 will return to the 

i 

SSVR 12 the binary representation, and ch^ge the command state to 
command in progress 420. If the state is no command 400 or aimmansl 
done 430, the call wiU fail, and the SSVR \L2 wiU display the SSVR 
prompt (SSVR>) to the user. An initial command state of command in 
progress 420 or ignore finish 440 implies a|bug in the SSVR 12 and may 
result in the CC 14 crashing the TCB 10. I 



In these embodiments, if the command state was command 
submitted 410, then the CC 14 will return to the SSVR 12 the binary 
representation of the requested command. 



4.9 Display of Command to Usgr 



Once the parsed command has beerk returned to the SSVR 12, 

I 

the SSVR 12 will determine if the commajid requires confirmation at 

I 
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process 140 (FIG. 4B), Confirmation should generally be required for ^ 
commands which request modification of information. Commands that 
do not alter the information, such as the viejwing of information, should 
not generally require confirmation. For purposes of confirmation, 
redirecting the display into a file should be [considered as viewing 
information. S 

The decision of whether a given command should require 
activation of the secure-attention key to execute depends on the basic 
security policy of the system. In one embodiment, secure-attention 
trusted commands aic a mechanism for use | by system managers, security 

managers, operators, and holders of special j privileges. 

j 

Generally, a command which is not a direct command, is a 
secure-attention command if: 

a. it modifies a security kernel 



database in a security-relevant 



way; or 



b. it displays information on which a 
systems manager, security maxjager, or 
operator will base a security decision. 
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1 If the command is one that does not require confirmation, the ^ 

2 TCB 10 enforces the system's security policy and determine if the user 

3 has the necessary access rights to execute the command at process 145. 

4 If this is the case the TCB 10 attempts to Execute the binary 

5 representation at process 150. Since certain commands, e.g. commands 

6 that merely display information, do not chaijige the state of the system, 

7 user confirmation is not required. There is| no security problem in not 

8 confirming these commands since the systenji only allows users to view 

9 information to which they have access. 
10 

11 There are certain commands that ch^mge the state of the system 

12 may not require confirmation. Some comn ands may allow the user to 
3 turn on a file to receive the user's redirectisd output. This files are 

14 sometimes known in the art as "listing files]" Generally, the turning on 

15 of a listing file is a confirmed command. 
16 

17 In situations; where a listing file has been tumed on (i.e., the 

18 output is redirected into this file) commands which normally display 

19 information may, by writing to the listing 4le, alter the state of the 

20 system* In these cases, confirmation of th^sc commands is generally not 

21 required because the flow of information ii constrained by the TCB's 

22 security rules, 
23 
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When a command requesting the disf^ay of information is 
executed by the TCB 10, the SSVR 12 resp(^nds by displaying a 
complete representation of the requested co^and as well as the 
requested information, i.e. the standard hum^n-readable representation of 
the command. In one embodiment, the SSVR 12 displays the function 
code, command modifiers, and command pa^-ameters all in unambiguous 
notation. If employed, the process ED may jalso be displayed. 

Thus, if the user's command is imprqperly parsed, or modified in 
an unauthorized manner, the user will be able to observe the difference. 
This inhibits an untrusted subject from fooljng a user into believing that 
he or she is observing the results of a subnjiitted command, when in fact 
that command had actually been altered. 

If the command requested is one foii which confirmation is 
required, the SSVR 12 displays a standard human-readable 
representation of what is about to be done to the user terminal at 
process 170. The code representing each <jommand should produce a 
different display, unless the commands havjs the same effect. As 
previously discussed, the re-display of the iction that a binary 
representation wiU. perform is less complexi than the parsing of the 
original command. This is in part because by definition there is only 
one standard human-readable represcntatipn for each parsed command. 
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1 By parsing the command in untrusted code, and verifying the ^ 

2 request in trusted code, the overall complexitjy of the TCB 10 is 

I 

3 decreased. The display of "what is about to |be done" may of course 

4 vary from one command to another. 
5 

6 If the command's purpose is to add a; record to a database or 

7 create an object, the display may contain whjat the new record will 

8 contain, or what the attributes of the object hvill be if the command is 

9 confirmed. 

10 I 

11 If a particular database or object is to be modified, the display 

12 may show what the updated data will look like, or what the attributes of 
3 the object will be if the command is confinied. For commands which 

14 remove an existing object, or delete an exis^g file, the display may 

15 show the record or object 
16 

17 Generally, for both adding/creating apd modifying, the data 

18 packet representing the submitted command! may contain fields for the 

19 objects attributes, such as its name, its size jand its protection. For each 

20 of these fields, the packet may also have a Iflag indicating whether the 

21 field is meaningful., These flags indicating ineaningful fields may be 

22 know as "field selectors." 
23 
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1 In add/create commands, the TCB miy supply default values for ^ 

2 unselected fields. In commands which modi^ a database entry or object, 

3 unselected fields may retain their previous v^ues. 

4 i 

5 To aid the user, the selected fields mky be highlighted when 

6 displayed for confirmation. Such highlighting may be accomplished by 

i 

7 methods known in the art (e.g., by using escape sequences that begin 

8 and end reverse video). This highlighting djaws the users attention to 

! 

9 the fields that have non-default or changed yalues and helps to protect 
10 the user from tricks by untrusted code. 

11 

12 When an audit record is produced of the confirmation display via 

3 the sink (discussed below) the reverse-videoi escape sequences may be 

14 replaced with dashes on the next line. Exajnple: 
15 

16 Name:JOHN.DQE 

17 

18 This change permits the audit record to be properly displayed on 

19 a wide variety of devices, even simple line printers. 
20 

21 Alternative embodiments are envisioned in which the TCB checks 

22 each field's value: for add/create commands the fields that have non- 
23 default values are highlighted; and for modify commands the fields that 
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1 are changing are highlighted. This "field cornparison" approach generally^ 

2 results in less highlighting. 

3 : 

4 Generally, for every command, every jpacket field is displayed on 

5 the screen, except for fields ignored by the particular command. 

6 

7 In the cases when a database will not be modified, the display 

8 generated by the SSVR 12 may express wh^t action is to be done. In 

9 this manner, the possibility of an erroneousj confirmation is reduced since 
10 the user is requested to confirm the results; not the command. 

11 

12 The SSVR 12 may also display a list of user protection attributes 

.3 so that the user knows what role he or sh6 is exercising. The user is 

14 required to confirm explicitly (Yes or No) fhe action requested. In a 

j 

15 general embodiment, the TCB 12 displays for confirmation the results 

16 which would occur if the command is executed. 
17 

18 Generally, any information in the b^iary representation that is 

19 displayed is first validated. This infonnatii)n is checked once to ensure 

20 that certain requirements are met, e.g., to iensurc that the counts of 

21 array elements are within array bounds (sijice out-of-bounds conditions 

22 could provide an opportunity for entry int^ the TCB by illicit software). 
23 
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Before displajdng the contents of a paclket containing the binary 
representation of the command, anything that could cause the formatting 
code to malfunction may be validated. Generally, such candidates for 
validation could include anything used to index into something else. 
Specific examples include the PASCAL language's implementation of 
varying strings (a count followed by an array j of characters; the count is 
checked to be less than or equal to the character array size), and 
numbers that represent keywords (their valu^ is checked before it is 
used to index into an array of keyword text ^trings). Further methods of 
validation are well known in the art and will not be discussed herein. 

In one embodiment, the replies that the user may make to the 
confirmation prompt are "y«s", "no", Ctrl-Q ttrl-Y, or the BREAK key. 
No default responses exist in this embodiment. For each user response, 
the secure server may display a message res^ting the response. K the 
response was "y^s" or "no", the secure serve( 12 displays an indication of 

the computing session in the UOS 20 when| it is being be resumed after 

i 
I 

command completion. j 

If, however, the user activates the Cirl-Y, Ctrl-C, or the BREAK 
key, the command will be aborted. In one embodiment, the CC then 
changes the command status code to negative. This may be done to 
inform the submitting process that the command has been aborted. In 



these cases a direct session with the SSVR^ 



12 will be established at 



process 300. In these instances, the user must explicitly issue a resume ^ 
command to return to the session in the UO$ 20. 



If the user conjarms the results or compiand, by replying with 

j 

"yes", or if the command does not require coijifirmation, the TCB 10 
enforces the system's security policy at process 145. At this process the 
TCB 10 determines if the user has the necessary access privileges to 
perform the requested activity. If the user h^ the required access 
rights, the SSVR 12, along with other code i^ the TCB 10 attempts to 
execute the conmiand in a conventional manher. 



Upon attempted execution of the command, the SSVR 12 may 
inform the CC 14 of the execution status. In some high-security 
situations, concern for information flow fron^ trusted to untrusted code 
will prevent informing the CC 14. The CC 14 may change the 
command status to indicate the SSVR 12 reiponsc. In addition, in 
alternate embodiments, the CC 14 changes tjie command state from 
rnmmand in propess 420 (FIG. 7) to mmn^and done 430. In these 
cases, the CC 14 notifies the submitting unthisted subjert by traditional 
methods (eg., by advancing an eventcount f^r that process). The SSVR 
12 then reestablishes the terminal connection with the computing session 
in the UOS 20 from which the command w^a executed. 
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In embodiments utilizing the status code, if the user responds with 
"no", the secure server informs the session ip. the UOS 20 that the 
command was not executed (negative status jcode). If command states 
are also employed, the SSVR 12 changes thfc command state to 
command done, arid re-establishes the user'^ session in the general UOS 
20 at process 160. 

If the trusted command requested by I the user is a command 
which affects one of the system databases, ^d the database record was 
changed by some other process or user betv^een the time the 
confirmation display appeared and the currdnt user confirmed the 
command, then the SSVR 12 displays a me^ge indicating that a change 
has been made and requests reconfirmation,! In this case, the SSVR 12 
waits for a response as if it were the first ti^e the information was 
displayed. 

To ensure tliat if two users attempt tp modify the same element 
at the same time, only one request is rejected, the TCB may utilize 
identifiers known as "modification counts" (ijiod-counts). 

Each element of key databases (or re^gistries) may contain a 
modification count This mod-count is advabced after each modification 

! 

and thus identifies how many modifications Jiave been made to the 
database element. Thus, when a user attempts to modify a database 



! 

1 element, the SSVR 12 first obtains that da^base element's mod-count. ^ 

2 After the user has confirmed the request, tlje TCB 10 checks the mod- 

3 count in the request against the current moji-count- 

4 ' 

5 A different mod-count indicates that a change has been made to 

6 the database element, and the user is asked to reconfirm the request 

7 since the result previously confirmed by the | user is not what the result 

j 

8 would actually be. i 
9 

10 To deter malicious users or subjects from preventing the execution 

i 

11 of trusted commands, two measures may bej taken. First, certain access 

12 rights may be required to change certain database elements. Second, 

3 the mod-count should not be advanced wheti a modification is requested 

14 that does not change the database elementl In this manner, attempts by 

15 malicious subjects to prevent execution of ^ trusted command, by rapidly 

16 and spuriously causing the mod-count to bej incremented, will be 

17 inhibited, 
18 

19 Once activity in the SSVR 12 is con^pleted, the user's session in 

20 the general UOS 20 is reestablished. In oni embodiment, this may be 

21 acconq)anied by tiie CC 14 informing the ijntrusted subject of the status 

22 of the submitted command. The, untrustedi code in the general UOS 20 

23 then wakes-up the untrusted process nmnii^g in the UOS 20 at process 

24 ' 160. In one embodiment, before the TCB 1 10 passes the user to the 



untrusted subject, the SSVR 12 prompts ttie user to activate a carriage ^ 
return. This step is necessary to inform the user that he/she is being 
placed into an untrusted environment. 

4.10 The SSVR a.s an Audit R«..rr>^^^r 

In one embodiment, the SSVR 12 audits (i.e., creates an audit 
trail by writing to an audit or log file) at ^he command level. For direct 
commands the SSVR 12 audits both the cpmmand line and the final 
status of the command. For trusted comnjiands (secure-attention 
commands), the SSVR 12 audits both the Iconfinnation display and the 
final status of the command. 



To record the confirmation displays^ the SSVR 12 defines a 
portion of memory to store the strings of information sent by the SSVR 
12 to the user's terminal. In one embodii^ent, this portion of memory is 
known as the "sink." Only the strings tha^ comprise the SSVR's 
confirmation screens are placed in the sink. 

Strings may be appended to the sin|c only when the sink is 
opened The sink is opened when the SSVR 12 begins to service a 
trusted command. The sink may be closejd after the user has responded 
to the confirmation prompt, or before thej display of certain requested 
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informatioa The information stored in th0 sink does not include the 
user input to any prompts. ! 



The information stored in the sink iS maintained for auditing 
purposes and may be utilized according to traditional auditing practices. 

4.11 Confirmatipn bv Others thap thg jSubmitting Usgr 

In some situations it may be desirable for users other than the 
submitting user to confirm a secure-attentidn command. Such a situation 
may arise if there is a certain application cfr command file that includes 
a privileged command but is needed to be inm by a large number of 
users. In the cases where it may be impra^cable to grant all of the 
users the necessarj^ access rights, it may bej possible to grant one user 
the necessary rights, and to allow him/her |to confirm this command for 
the other users. 

Such non-submitting user confirmation may be accomplished by 
having the code in the untnisted subject li^ about which user is 
submitting the coaimand. For example, th^ code in the UOS 20 may 
ensure that certain commands are always s^nt to the TCB 10 as if they 
had been submitted by a selected user. 
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1 One purpose of this select user woul4 be to confirm these certain 

2 commands for the other users. After a noi^-select user submits one of 

I 

3 the certain commajads, the selected user wilj be notified that there is a 

4 submitted command waiting. The select usir may then observe the 

5 confirmation display. If the select user determines that the conunand 

i 

6 submitted was a legitimate command, he/sh^ may confirm the command. 

7 Otherwise, the original users attempt to exe^te the command fails, 
8 

9 4.12 Implementat ion Approache?; | 

10 , 

11 The method for executing trusted coibmands described above may 

12 be implemented through the use of appropriate software. The actual 
3 design and coding its a matter of routine for those skilled in the art 

14 having the benefit of this disclosure. Such k design will of course vary 

15 with the hardware platform and other facto|^ associated with the specific 

16 desired implementation* 
17 

18 FIG5 illustrates one such method fot implementing the present 

19 invention. A programmable machine comprises a central processing unit 

20 (CPU) 210, and an input/output (I/O) device 220. The I/O unit 220 is 

21 capable of reading and transmitting stored j)rogramming instructions 

22 from known storage media 230. The CPU 1210 is capable of processing 

23 these instructions and executing the prograiWing steps represented on 
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1 media 230. Such systems are well known in the art and will not further-^ 

2 be described. ' 
3 

4 To implement the invention, the neclessary programming steps are 



methods. The storage media 
he programming instructions 



5 stored on storage media 230 by traditional 

6 230 is then read by the I/O unit 220 and 

7 are transmitted to the CPU 210. The CPI^ 210 reads and interprets the 

8 instructions, and may thereafter carry out ^e method of the invention. 
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CLAIMS 



WHAT IS CLAIMED IS: 

1. A machine-executable method for executing a trusted command 
issued by a user, said method comprising the steps of: 

(a) parsing the trusted command iti an untrusted computing 
environment to generate a paried command; 

(b) submitting the parsed conmianji to a trusted computing 
environment; and 

(c) executing the parsed commanc^ in the trusted computing 
environment. 



2. A method including the steps of clai^ 1 and additionally including 
the steps, executed after step (b) of tlaim 1, of: 

(1) in the trusted environment, displaying a representation of 
the parsed command to ±e u^er; 
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(2) receiving a signal from the usejr signifying whether the 
displayed representation accurately represents the usefs 
intentions; 



(3) if the signal signifies that the displayed representation does 
not accurately represent the us|er*s intentions, then 
preventing the performance of step (c) of claim 1. 



The method of claim 2 wherem the Representation of the parsed 
command is displayed, and the signalj from the user is received, 
through a ttusted path. 



The method of claim 1 wherein the ^rusted computing 

I 
i 

environment comprises a security kerpel 



The method of claim 1 wherein the imtrusted computing 
environment comprises a general operating systeuL 
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A method for executing in a computing 
issued by a user, said method 



system a trusted command 
compr^smg the steps of: 



(a) recei\ing user identification d^ta from the user via a 
trusted path; 

(b) receiving the trusted command from the user via an 
untrusted path; 

i 

! 

(c) parsing the trusted command in an untrusted computing 
environment to generate a pa^d command; 

(d) submiitting the parsed commaijid to a trusted computing 
environment; 



(e) in the trusted computing 

check: on the parsed commani 
and 



environment, performing a security 
and user identification data; 



(f) in the trusted computing environment, executing the trusted 
command 
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The method of claim 6, wherein th^ security check enforces an 

j 

Orange Book security criterion, I 



A method including the steps of clsjim 6 and additionally including 
the steps, executed after step (d) ai^d before step (f) of claim 6, 
of: 

(1) in the trusted enviromjnent, displaying a 
representation of the parsed command to the user; 

(2) receiving a signal froni the user signifying whether 

i 

the displayed represenbtion accurately represents the 
trusted command; andj 

(3) if the signal signifies that the displayed 
representation does ncjt accurately represent the 
trusted command, thei^ preventing the performance 
of step (f) of claim 6.i 
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A method including the steps of claini 6 and additionally including 

i 

the steps, executed after step (d) and before step (f) of claim 6, 

of: ^ 

(1) in the trusted environment, displaying a 
representation of the pajsed command to a second 
user; 

(2) receiving a signal from ^e second user signifying 

i 

whether the displayed representation accurately 

! 

represents a legitimate <}ommand; and 

(3) if the signal signifies thit the displayed 
representation does not laccurately represent a 
legitimate command, th^n preventing the 
performance of step (f) |of claim 6, 



A method for ensuring the existence iof a trusted path in a 
computing system comprising the stej^s of: 
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(a) in a trusted computing envirorunent, upon login by a user, 
assigning a process identifier tb the user in the trusted 
computing environment; ' 

(b) storing the assigned process identifier in trusted memory; 

(c) establishing a trusted path; 

(d) in the trusted path, displaying I the process identifier to the 
user; and 

(e) upon a subsequent entry into ^he trusted path, displaying 
the process identifier to the u^er. 



The method! of claim 10 wherein thej process identifier is a 
randomly or pseudo-randomly generated group of alphanumeric 
characters. 



The methodl of claim 11 wherein the process identifier is 
pronounceable. 
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1 

2 

3 ; 

4 13. An automatic data processing machiite programmed to execute the 

5 method of any one of claims 1 to 121 
6 

7 
8 

9 14. An automatic data processing machii^e comprising means for 

10 performing the method steps of any |)ne of claims 1 to 12. 

11 ^ 
12 

3 

14 15. A program storage device readable \^ a machine and tangibly 

15 embodying a representation of a pro-am of instructions adaptable 

16 to be executed by said machine to perform the method of any 

17 one of claims 1 to 12. 
18 

19 
20 
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Apparatus for executing a trusted cotnmand that is issued by a 



user and that is parsed by untrusted 
parsed command, comprising: 



parsing means to generate a 



(a) trusted means for receiving the parsed command; and 



(b) 



trusted means for executing tlje parsed command. 



Apparatus for controlling the executiion by a machine of a trusted 
command that is issued by a user arid that is parsed by untrusted 
parsing means to generate a parsed jcommand, comprising: 



(a) trusted-program storage meanjs, readable by the machine, 
for causing the machine to receive the parsed command 
from the untrusted parsing m^ans; and 



(b) tnist<^-program storage means, readable by the machine, 
for causing the machine to execute the parsed command. 
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10 

11 
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14 

15 

16 

17 

18 

19 
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18. Apparatus for controlling the execution by a machine of a trusted^ 

command that is issued by a user w|th user identification data and 

i 

that is parsed by untrusted parsing i^eans to generate a parsed 

i 

command, comprising: I 

(a) trusted program storage meai^, readable by the machine, 
for causing the machine to receive the user identification 
data fi-om the user; 

I 

(b) trusted program storage meaiis, readable by the machine, 
for causing the machine to rejceive the parsed command 
from the untrusted parsing means; 



(c) trusted program storage meaijs, readable by the machine, 
for causing the machine to perform a security check on the 
parsed command and a security check on the user 

j 

identification data; and 

I 

! 

(d) trusted program storage meaiks, readable by the machine, 
for causing the machine to execute the trusted command. 
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Apparatus £ts in claim 18 and additicjnally comprising: 



(1) trusted program storage meanjj, readable by the machine, 
for causing the machine to display a representation of the 
parsed command to the user; ! 



(2) trusted program storage mean^, readable by the machine, 
for causing the machine to receive a signal from the user 
signifying whether the displayed representation accurately 
represents the trusted commaijid; and 



(3) trusted program storage mean^, readable by the machine, 
for preventing the machine fr<j)m executing the trusted 
command if the signal signified that the parsed command 
does not accurately represent jthe trusted command. 



Apparatus as in claim 18 and additionally comprising: 



(1) trusted program storage means, readable by the machine, 
for causing the machine to display a representation of the 



parsed command to a second 



user; 



(2) trusted program storage mearis, readable by the machine, 
for causing the machine to rc<;eive a signal from the second 
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user signifying whether the displayed representation 
accurately represents a legitimate command; and 



trusted program storage mean^, readable by the machine, 
for preventing the machine frbm executing the trusted 
command if the signal signifie^ that the parsed command 
does not accurately represent ^ legitimate command. 
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1 ABSTRACT ^_ 

2 

3 A method for executing trusted commands, in which a trusted 

4 command is first received from a user at a i^ser terminal and parsed by 

5 untrusted code; then passed to a trusted con^puting base for execution. 

6 The trusted computing base displays some iiidication of what is to be 

7 done back to the user for conjBrmation. Co^ifirmation of the commands 

8 prevents unauthorized modification of the cdmniands and increases 

i 

9 system confidence, A randomly (or pseudo-randomly) generated process 
10 identifier is employed to verify the existence j of a trusted path. 

11 
12 
3 

15 
16 

17 g:\digu\012\08.toe 
18 
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